2007-08

にっき

開発日記

何故Ｄ＋、Ｄ−をＰＢ１，ＰＢ０に繋ぐ例が多いのだろうか？†

  • IgorPlugUSBなどを見てもそうなっているようだ。
  • Igorさんの実装はＡＴ９０Ｓ２３１３、ＡＴ９０Ｓ２３２３とＡＴｍｅｇａ８の両方をサポート。
  • ９０Ｓ２３１３（２０ピン）ではＰＢ１をＰＤ２（ＩＮＴ０）にも接続する。
  • ９０Ｓ２３２３（８ピン）はＰＢ１がＩＮＴ０になっていて、ＰＤが存在しない。
  • 他にもＴｉｎｙ４４、Ｔｉｎｙ４５などの１４ピン品種、８ピン品種はＰＢのみであり、ＰＤが存在しない。

というわけで謎が解けた。

  • ８ピン品種と（アセンブラ）ソースをなるべく共用したい場合は、２０ピン品種の１本が無駄になることなんて、たいした問題ではないのだ。
  • むしろアセンブラレベルでポートを書き分けるほうが面倒だ。（それに比べ配線１本の手間なんてわずかなもんだ）
  • その点、対比するとＡＶＲＵＳＢのＣソースのカスタマイズ性はなかなかのものだ。

ＡＶＲ＿Ｍｏｎｉｔでは、ＰＯＲＴＢを完全フリーに出来るというメリットがあるのでconfig設定をPD3,PD2のほうに振ってしまった。

  • が、他の少ピン品種でやりたい場合はPB1,0に戻さなければならないわけだ。
  • もっとも、これは大した手間ではなく、usbconfigの書き換えと、ポート初期化を少し変えるだけで済む。
↑

About IgorPlugUSB ...†

  • Ｄ＋、Ｄ−の配線が違うので、配線しなおし。
  • 秋月の片面ユニバーサルは半田はがしをやるとパターンが剥げやすい。
    • というか単純にこてがしょぼいということにして、実は半田の腕が落ちている言い訳。
  • ＡＴ９０Ｓ２３１３だったけどそのままｔｉｎｙ２３１３に焼いてみた。
  • きっちり２ｋＢだった。
    • 付属のApplicationを起動して、動作を確認。
    • しかし、TeraTermのＣＯＭ３：に出てこない。
    • そゆもの？？？

こゆものがあった。

  • 世の中便利に出来てるのね。
  • と思ったら、これシェアウェア？
    • デモは19200までで、57600にしたかったら製品を買えという落ちか。
↑

つまり、こういうことか？†

  • IgorPlugUSBは、まるでAVR_Monitのような切り口で作られていてＤＬＬを呼び出せばＡＶＲを自由に操れる。
  • ついでにシリアルポートもコントロールしているので、ＲＳ２３２Ｃ通信が出来る。
  • だが、付属のアプリケーションウィンドウ内とか、ＤＬＬを呼び出す形の端末ソフトを書かない限りＲＳ２３２Ｃを受けられない。
  • ＣＯＭ：に変換するＷｉｎ版ドライバーはシェアウェア。
  • Ｌｉｎｕｘカーネル２.６系ではIgorPlugUSBをＣＯＭ：にするドライバーが書かれている。

こゆこと？

  • 自分はつくづくＡＶＲ無知であることを思い知らされる毎日（びしっ！）
↑

結局ＵＳＢ-シリアルコンバータは作れない！？†

  • 頼みの綱だったIgorPlugはＣＯＭ：になれない。
  • ＡＶＲ-ＣＤＣは最小限に切り詰めてなお２５６バイト以上足が出ている。ｔｉｎｙ２３１３ではどうあがいても無理っす。
  • あとは、なんちゃってシリアルでも作る？実用性ないけど。
↑

ComEmulDrvについて†

http://mixw.net/related.htm#tncemu

  • こんなものがあった。
  • 物理ポートがＣＯＭ４まであるとする。
  • こいつはＣＯＭ５：とＣＯＭ６：を仮想的に作成。
  • 物理ポート、たとえばＣＯＭ１：とＣＯＭ２：をクロスケーブルで結んでみよう。どうなるか。
  • それと同じことをこのドライバーで行ない、ＣＯＭ５：の送信データはＣＯＭ６：で拾えるというわけだ。

こいつは便利かも。

  • だってWin32APIのCreateFile()でCOM5:をオープンするだけでしょ？
  • なんちゃんてＣＯＭポートドライバーをCOM5に繋いでおけば、TeratermからＣＯＭ６経由でＡＶＲに接続完了！ナイスアイディア！

試してみた。

  • COMポートに対するReadFileとWriteFileは競合するようだ（別スレッドで動かしても）。非同期モードを使うしかない。
↑

なんちゃってシリアルアダプターの設計†

  • シリアル受信バッファ 
       0      1      2      3      4      5      6      7
+------+------+------+------+------+------+------+------+
| size |         受信データ（最大７バイトまで）         |
+------+------+------+------+------+------+------+------+
    sizeフィールド下位４ｂｉｔには０〜７までの数字（バイト数）が入る。
    sizeフィールド上位４ｂｉｔにはRS232Cのラインステータスを入れる。
  • 受信バッファは２組〜４組用意してラウンドロビン。
  • 受信バッファにはRxDataの割り込みルーチンが直接データを入れる。
  • ＵＳＢバルク（あるいはコントロール）受信のリクエストが来たら 有効で最も古い受信バッファを送信する。
  • シリアル送信データ 
       0      1      2      3      4      5      6      7
+------+------+------+------+------+------+------+------+
| size |         送信データ（最大７バイトまで）         |
+------+------+------+------+------+------+------+------+
  • コントロール転送のときは 
       0      1      2      3      4      5      6      7
+------+------+------+------+------+------+------+------+
|ReqTyp| cmd  | 送信データ（最大４バイト）| wLength     |
+------+------+------+------+------+------+------+------+
    cmdフィールド下位５ビットにはCMD_SENDコマンド(0x03)を入れる。
    cmdフィールド上位３ビットが送信データのサイズ。
↑

ＳＰＩバスの使い方†

ＥＬＭ　ＣｈａＮさんの説明

ＭＩＣＯＭ　Ｊｏｕｒｎａｌ

最大２０ＭＢＰＳ！これは美味しい。

  • ＳＰＩはマスターがクロックを送り、スレーブとマスターの８ビットシフトレジスタの値を交換するやりかたでデータ転送する。
  • ＡＶＲのＳＰＩプログラミングでは４バイト固定長でコマンドを送る。
  • データ受信は、わりと最後の１バイトの転送時に交換している。
    • コマンド解釈が完了しないとデータの返送はできないから。
    • コマンドは最初の２バイトで確定し、後ろの２バイトはデータだったりダミーだ。

これをＲＳ２３２代わりにしようとすると、こんな感じか？

  • シリアル送信データ 
       0      1    
+------+------+
| SEND | char |   SEND = 0xf1、NULL_SEND = 0xf0 とか固定。
+------+------+
  • シリアル受信データ 
       0      1    
+------+------+
| RECV | char |   RECV もSENDと同じ。
+------+------+
  • 上記の２バイトペアを交換するイメージ。
  • 本当は９ビット受け取れるならＭＳＢをデータ有効フラグに出来る。
  • ＲＳ２３２Ｃは自発的にデータが送られてくるが、ＳＰＩの場合、ＵＳＢのように必ずマスターがスレーブに働きかける必要がある。
  • ２バイトのパケットを互いに交換する。
  • 送信データがない場合はNULL_SEND を送る。charは０にする。
  • 受信データがない場合もNULL_SEND を送る。charは０にする。

もしも、伝送路が文字列に限定され、＾＠（￥ｘ００）は決して送られないか、捨ててよいというのであれば、１バイト単位の交換で出来る。

  • お互い、送りたいデータがなければ０を送る。
  • あるいは、エスケープ文字コードを１つ設定（めったに送られない文字、たとえば０ｘＦＤとか決める）して、エスケープ処理をする。
  • お互い、１バイト単位でバイナリーデータを送る。
  • 送るデータがなければ０を送る。
  • エスケープ文字が来た場合、 
    0xFD , 0xF0 == バイナリーの 0x00 に置換。
0xFD , 0xF1 == バイナリーの 0xFD に置換。
  • とか取り決めておく。

ＡＴｔｉｎｙ２３１３の１２ＭＨｚでＳＰＩ転送すると仮定して、

  • ３命令のループで１ビット送信を組んだ場合、ＳＰＩのマスタークロックが約４ＭＨｚ
  • １バイト送るのに約３マイクロ秒くらい？
  • オーバヘッドも考慮して５マイクロとすると、２００ｋＢ/Ｓくらい。
  • もちろんＡＶＲにそんな（２００ｋＢも）メモリーはないけど。
  • ＵＳＢ　ＬｏｗＳｐｅｅｄの物理速度くらいは超えられる。

むりやりＲＳ２３２風にせずとも、

uchar read_data = spi_read( write_data );

みたく、交換形式でハンドシェイクすればいいのか。そうか。

  • それはＡＶＲ同士の送受信ではＯＫだが、ＴｅｒａＴｅｒｍをつないでＲＳ２３２風にやりとりする場合にちょっと困る。
↑

なんちゃってシリアルアダプターのコーディング†

  • コントロール転送版AVR_Monitが役に立った。
  • バルク転送版ファームのコマンド受信部をコントロール転送版に差し替え。
  • 両方のパケットを受け付けられるようになった。
  • monit.exeでAVR_Monitとして作動することを確認。
  • さらにバルクパケットの送受も出来た。

バルク転送でＲＳ２３２Ｃの転送を行なう。

  • 受信については、受信割り込みで３２バイトのFIFOに貯める。
  • バルク送信のタイミングでそれから７バイト以下を切り出してホストに送る。

ここまでは簡単だが、

  • 送信が意外と難しいことが判明。
  • ボーレートが低いと、送信されたバルクデータをさばけないでＡＶＲ側に溜まってしまう。
  • ホストから送るのを待ってもらうしかない。
  • ちょっとまって信号をどうやって返すか、という点と、送信できなかった場合のパケットをどこに保存するか、あるいは再送するかを決める必要がある。

しかたがないので

  • バルク転送は８バイト送って８バイト受けるというルールにする。
  • 常に返送パケットを必要とするようにする。
  • 前回の送信データがさばききれてないときは送信パケットの内容を破棄し、返送パケットに破棄したことを伝えるビットを入れる。
  • ホスト側は再送が必要になる。

このような実装にした場合のスループットは

  • ＵＨＣＩでのバルク送信／受信の繰り返しだと１パケットに２ｍＳ掛かるようなので往復で４ｍＳ掛かる。
  • １サイクルで送受できるデータは、ＵＳＢ側の都合だけだと７バイト以内。
  • ２５０回掛ける７バイト＝１７５０バイト／秒＝１４０００ｂｐｓ。

どうやったら５７６００ｂｐｓに出来るのだろう？？？？

↑

なんちゃってシリアルアダプターの動作試験†

ここまで出来た。

ROM 1982 byte
RAM 119 byte
  • RAMが容量的にやばい.
  • ＲＯＭももうない。

どこまで書いたか？

  • ＲＳ２３２Ｃ受信割り込みでＵＳＡＲＴからデータを受け取りキューに貯める。
  • AVR_Monitのコントロール転送版にバルク転送を追加してシリアルデータのハンドシェイクを行う。
  • 送信バッファにランダムなデータを７バイト貯めてホストからバルク転送する。
  • ＡＶＲ側は受け取って送信キューにセット。
  • メインループ内で送信キューを１文字づつ送信。
  • 受信データがあればバルク転送でホストに返送する。
  • ＡＶＲのピン２（ＲｘＤ）とピン３（ＴｘＤ）を接続し、なんとなくエコーバックしているところまで確認した。

通信速度は？

  • ＵＳＢのバルク転送は１フレームに１回しか出来ない。
  • ＵＨＣＩだと２フレームに１回だ（何故か判らないが）
  • ８バイトのバルクパケットを送受するのも同一フレームでは出来ずそれぞれの２倍のフレームを消費する。
  • よって、ＵＨＣＩでは１４０００ｂｐｓ、ＳｉＳのＯＨＣＩに限りその２倍しか速度が出ない。

非同期でのＵＳＢ転送が出来れば速いのかもしれないが・・・

↑

ＵＳＢ２.０ＰＣＩカードを試す。†

同じマシンに２つのホストコントローラがある場合に、速度差があるかどうか調べる。

  • ＶＩＡ　ＶＴ６２０２のカードをＳｉＳ７４６Ｆに挿してみた。
  • ベンチ結果は以下のとおり
    ＵＳＢホストコントローラコントロール転送バルク転送
    SiS7001 EHCI(SiS746Fオンボード)8000bytes/秒8000bytes/秒
    VT6202(PCI)2000bytes/秒4000bytes/秒
  • ＣＰＵはＢａｒｔｏｎ(１８００ＭＨｚ)
  • 傾向的にはVT6202とVT8237(KM400などのサウスブリッジ)は大体同じ。
  • intelの８６５系も転送速度は同じくらい。
  • SiSだけが突出して速いのが相変わらず謎。
  • 最初はWindowsの設定の問題（レジストリ？）かとも思ったが、どうやらホストコントローラそのものが速度を決めているような感じ。
  • いくらＬｏｗＳｐｅｅｄが遅いからといって、１フレーム（＝１ｍＳ）に８バイトのペイロードは４回以上送れるはず(1.5Mbps == 1500bit/frame ≒ 150byte /frame ,８バイトにオーバヘッドが３倍あっても６回は送れるだろ？)。
  • ということはだな、ホストコントローラの設計が思い切りタコなのか、
  • libusbかusbドライバーが１フレーム単位に１回しか同期処理出来ないような構造になっているかのどちらかだな。